Metaobject Protocols.html

   1 <?xml version="1.0" encoding="utf-8" ?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   3     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   4 <html xmlns="http://www.w3.org/1999/xhtml">
   5   <head>
   6     <title>Metaobject Protocols</title>
   7     <meta name="generator" content="muse.el" />
   8     <meta http-equiv="Content-Type"
   9           content="text/html; charset=utf-8" />
  10     <meta name="viewport"
  11           content="width=device-width, initial-scale=1.0" />
  12     <link href="https://feeds.unknownlamer.org/rss/site-updates"
  13           rel="alternate" type="application/rss+xml" title="Updates Feed" />
  14
  15 <link rel="stylesheet" href="default.css" />
  16   </head>
  17   <body>
  18     <h1>Metaobject Protocols</h1>
  19    <div class="contents">
  20 <dl>
  21 <dt>
  22 <a href="#sec1">Background</a>
  23 </dt>
  24 <dd>
  25 <dl>
  26 <dt>
  27 <a href="#sec2">Object Protocols</a>
  28 </dt>
  29 <dt>
  30 <a href="#sec3">CLOS Way of OO</a>
  31 </dt>
  32 <dd>
  33 <dl>
  34 <dt>
  35 <a href="#sec4">Classes for Scratch Data and Types</a>
  36 </dt>
  37 <dt>
  38 <a href="#sec5">Generics with Methods that Implement Protocols</a>
  39 </dt>
  40 </dl>
  41 </dd>
  42 </dl>
  43 </dd>
  44 <dt>
  45 <a href="#sec6">Limitations of Default Language Behavior</a>
  46 </dt>
  47 <dd>
  48 <dl>
  49 <dt>
  50 <a href="#sec7">Slot Storage</a>
  51 </dt>
  52 <dt>
  53 <a href="#sec8">Design Patterns</a>
  54 </dt>
  55 </dl>
  56 </dd>
  57 <dt>
  58 <a href="#sec9">Metasoftware</a>
  59 </dt>
  60 <dd>
  61 <dl>
  62 <dt>
  63 <a href="#sec10">Runtime Generated Classes</a>
  64 </dt>
  65 <dt>
  66 <a href="#sec11">Object Inspection</a>
  67 </dt>
  68 </dl>
  69 </dd>
  70 <dt>
  71 <a href="#sec12">Metaobject Protocols</a>
  72 </dt>
  73 <dd>
  74 <dl>
  75 <dt>
  76 <a href="#sec13">Limited/Generalized Internals of the Implementation</a>
  77 </dt>
  78 <dt>
  79 <a href="#sec14">Classes of MOPs</a>
  80 </dt>
  81 <dd>
  82 <dl>
  83 <dt>
  84 <a href="#sec15">Reflective</a>
  85 </dt>
  86 <dt>
  87 <a href="#sec16">Intercessory</a>
  88 </dt>
  89 </dl>
  90 </dd>
  91 <dt>
  92 <a href="#sec17">Violation of Encapsulation?</a>
  93 </dt>
  94 </dl>
  95 </dd>
  96 <dt>
  97 <a href="#sec18">MOP Design Principles</a>
  98 </dt>
  99 <dd>
 100 <dl>
 101 <dt>
 102 <a href="#sec19">Layered Protocol</a>
 103 </dt>
 104 <dd>
 105 <dl>
 106 <dt>
 107 <a href="#sec20">Top Level <strong>Must</strong> Call Lower Level Methods</a>
 108 </dt>
 109 <dt>
 110 <a href="#sec21">Lower Level Methods are Easier to Customize</a>
 111 </dt>
 112 </dl>
 113 </dd>
 114 <dt>
 115 <a href="#sec22">Functional Where Possible</a>
 116 </dt>
 117 <dd>
 118 <dl>
 119 <dt>
 120 <a href="#sec23">Memoization</a>
 121 </dt>
 122 <dt>
 123 <a href="#sec24">Constant Shared Return Values</a>
 124 </dt>
 125 </dl>
 126 </dd>
 127 <dt>
 128 <a href="#sec25">Procedural Only Where Necessary</a>
 129 </dt>
 130 <dt>
 131 <a href="#sec26">Real World</a>
 132 </dt>
 133 <dd>
 134 <dl>
 135 <dt>
 136 <a href="#sec27">UCW and Arnesi</a>
 137 </dt>
 138 <dt>
 139 <a href="#sec28">CLSQL</a>
 140 </dt>
 141 <dt>
 142 <a href="#sec29">Elephant</a>
 143 </dt>
 144 </dl>
 145 </dd>
 146 </dl>
 147 </dd>
 148 <dt>
 149 <a href="#sec30">Sources and Further Reading</a>
 150 </dt>
 151 <dd>
 152 <dl>
 153 <dt>
 154 <a href="#sec31">Sources</a>
 155 </dt>
 156 <dd>
 157 <dl>
 158 <dt>
 159 <a href="#sec32">The Art of the Metaobject Protocol</a>
 160 </dt>
 161 <dt>
 162 <a href="#sec33">CLOS MOP Specification</a>
 163 </dt>
 164 <dt>
 165 <a href="#sec34">Metaobject Protocols: Why We Want Them and What Else They Can Do</a>
 166 </dt>
 167 <dt>
 168 <a href="#sec35">Why Are Black Boxes so Hard to Reuse?</a>
 169 </dt>
 170 </dl>
 171 </dd>
 172 <dt>
 173 <a href="#sec36">Further Reading</a>
 174 </dt>
 175 <dd>
 176 <dl>
 177 <dt>
 178 <a href="#sec37">A Metaobject Protocol for C++</a>
 179 </dt>
 180 <dt>
 181 <a href="#sec38">Open Implementations and Metaobject Protocols</a>
 182 </dt>
 183 </dl>
 184 </dd>
 185 <dt>
 186 <a href="#sec39">Software</a>
 187 </dt>
 188 <dd>
 189 <dl>
 190 <dt>
 191 <a href="#sec40">Closer to MOP</a>
 192 </dt>
 193 </dl>
 194 </dd>
 195 </dl>
 196 </dd>
 197 </dl>
 198 </div>
 199
 200
 201 <!-- Page published by Emacs Muse begins here -->
 202 <p>In Fall of 2006 I did a small project on Metaobject Protocols for my
 203 CS 331 class. Here lie my notes which may perhaps be useful to
 204 others. I hope to expand them into something more useful over time.</p>
 205
 206 <h2><a name="sec1" id="sec1"></a>
 207 Background</h2>
 208
 209 <h3><a name="sec2" id="sec2"></a>
 210 Object Protocols</h3>
 211
 212 <p class="first">An object protocol is a set of methods and specification of the
 213 interactions between the methods which provide some generic behavior
 214 (e.g. of a sequence) that are then implemented by classes which
 215 conform to the protocol (e.g. a vector or list). In most object
 216 systems a class contains both the methods which implement a protocol
 217 and the data used by the implementation. The intent is to emulate
 218 state machines which pass messages between each other.</p>
 219
 220
 221 <h3><a name="sec3" id="sec3"></a>
 222 CLOS Way of OO</h3>
 223
 224 <p class="first">The Common Lisp Object System (CLOS) is different. It separates
 225 the data and method concepts into classes and generics. A class
 226 contains data fields only, and a generic has methods specialized for
 227 certain types attached to it. This seems a bit weird at first, but is
 228 significantly more powerful as it encourages complete encapsulation
 229 through its use of classes primarily for method specialization rather
 230 than for state storage.</p>
 231
 232 <h4><a name="sec4" id="sec4"></a>
 233 Classes for Scratch Data and Types</h4>
 234
 235 <p class="first">In CLOS classes store data in slots (which are the same as data
 236 members). Encapsulation is not provided; any bit of code can use
 237 <code>slot-value</code> to access or set the value of a slot. This may seem odd at
 238 first, but encapsulation is of questionable importance as the slots
 239 are meant only to be used by the protocol defined around the class.</p>
 240
 241 <p>Classes are defined with <code>defclass</code></p>
 242
 243 <pre class="src">
 244 (<span class="emacs-face-keyword">defclass</span> <span class="emacs-face-type">name</span> (superclasses ...)
 245   ((slot-name <span class="emacs-face-builtin">:accessor</span> slot-accessor ...)
 246    ...)
 247   (class-options ...))
 248
 249 (<span class="emacs-face-keyword">defclass</span> <span class="emacs-face-type">example</span> ()
 250   ((foo <span class="emacs-face-builtin">:accessor</span> foo-of <span class="emacs-face-builtin">:initform</span> 5)))
 251
 252 (<span class="emacs-face-keyword">defclass</span> <span class="emacs-face-type">example-child</span> (example)
 253   ((bar <span class="emacs-face-builtin">:accessor</span> bar-of <span class="emacs-face-builtin">:initform</span> (list 1 2 3))))
 254 </pre>
 255
 256 <p>Slot definitions have several options; the above example shows only the
 257 <code>:accessor</code> and <code>:initform</code> options which are the most commonly
 258 used. <code>:accessor</code> generates an accessor for the slot (e.g. if you have
 259 an instance of <code>example</code> you can <code>(setf (foo-of some-example-instance)
 260 'some-value)</code> to set and <code>(foo-of some-example-instance)</code> to access the
 261 value). <code>:initform</code> provides a default initial value for the slot as a
 262 symbolic expression to be evaluated when an instance is created in the
 263 lexical environment of the class definition.</p>
 264
 265
 266 <h4><a name="sec5" id="sec5"></a>
 267 Generics with Methods that Implement Protocols</h4>
 268
 269 <p class="first">Generics are like normal functions in Lisp, but they only provide a
 270 lambda list (parameter list). Methods are added to the generic which
 271 specialize on the types of their parameters and provide an
 272 implementation. This allows writing rich layered protocols which can
 273 enable selective modification of individual facets with minimal code.</p>
 274
 275 <pre class="src">
 276 (<span class="emacs-face-keyword">defgeneric</span> <span class="emacs-face-function-name">generic</span> (parameters ...)
 277   (options) ...)
 278
 279 (<span class="emacs-face-keyword">defmethod</span> <span class="emacs-face-function-name">generic-name</span> ((parameter type) parameter ...)
 280   <span class="emacs-face-doc">"documentation string"</span>
 281   body)
 282
 283 (<span class="emacs-face-keyword">defgeneric</span> <span class="emacs-face-function-name">foo</span> (bar baz quux)
 284   (<span class="emacs-face-builtin">:documentation</span> <span class="emacs-face-doc">"Process the baz with the quux capacitor to make the
 285 foo widget fly into the sky at warp speed"</span>))
 286
 287 (<span class="emacs-face-keyword">defmethod</span> <span class="emacs-face-function-name">foo</span> ((bar example) baz (quux capacitor))
 288   (launch bar (process-with quux baz)))
 289 </pre>
 290
 291 <p>A method lambda list differs from a normal lambda list only in that it
 292 can specify the type of the parameter using the notation <code>(name type)</code>.
 293 Note also that methods can specialize on the types of every
 294 argument and not just the first one. This is quite powerful for
 295 reasons outside of the scope of this presentation.</p>
 296
 297
 298
 299
 300 <h2><a name="sec6" id="sec6"></a>
 301 Limitations of Default Language Behavior</h2>
 302
 303 <p class="first">The behavior of a language is a compromise between many competing
 304 issues that attempts to be as generally useful as possible so that
 305 <em>most</em> applications will have no issue with the default behavior. There
 306 are, however, certain applications that could be cleanly written with
 307 minor modifications to the behavior of the language, but would be
 308 impossible or quite difficult to write otherwise.</p>
 309
 310 <h3><a name="sec7" id="sec7"></a>
 311 Slot Storage</h3>
 312
 313 <p class="first">Most languages choose to preallocate storage for all of the slots of
 314 an instance. Now imagine a contact database that stores information
 315 about people in slots of a class. There may be dozens of slots, but
 316 often many of them will be left blank. If slot storage is preallocated
 317 much memory will be wasted and the database may not be able to fit
 318 into the memory of the hardware it must run on (perhaps for financial
 319 reasons, huge datasets, etc.).</p>
 320
 321 <p>To save memory the author of the contact database must implement his
 322 own system to store properties and allocate them lazily. This
 323 represents a fair bit of effort, and would implement a system that
 324 differed from the existing slot system of classes only regarding slot
 325 storage.</p>
 326
 327 <p>It would be useful if there were a way to customize slot allocation in
 328 instances. The customizations would be minor and require overriding
 329 only the initial allocation behavior and the behavior of the first
 330 assignment to the slot. It is a a trivial problem in a language that
 331 allows customization of these behaviors.</p>
 332
 333
 334 <h3><a name="sec8" id="sec8"></a>
 335 Design Patterns</h3>
 336
 337 <p class="first">Design Patterns are generalized versions of common patterns found in
 338 programs. Many of them are merely methods to get around deficiencies
 339 in the language, and can be quite messy to implement in some
 340 languages. Ideally a pattern would be subsumed by the language, but
 341 real world constraints require language standards to remain fairly
 342 static.</p>
 343
 344
 345
 346 <h2><a name="sec9" id="sec9"></a>
 347 Metasoftware</h2>
 348
 349 <p class="first">Some types of programs could be written easily if the language were
 350 customizable but are nearly impossible to write when it is not.</p>
 351
 352 <h3><a name="sec10" id="sec10"></a>
 353 Runtime Generated Classes</h3>
 354
 355 <p class="first">Say you wanted to write a video game where players could create their
 356 own objects, attach behaviors to the objects, and perhaps mix
 357 different objects together to create new ones. When you abstract the
 358 problem this looks just like an object system!  Wouldn't it be nice if
 359 your program could create new classes and methods on the fly portably?</p>
 360
 361
 362 <h3><a name="sec11" id="sec11"></a>
 363 Object Inspection</h3>
 364
 365 <p class="first">Imagine you were developing a complicated program with many different
 366 objects that interacted in fairly complex ways. A tool to inspect the
 367 structure of objects while debugging would be quite useful, but in a
 368 traditional language would be impossible to implement portably. This
 369 could force you to purchase a certain compiler implementation which
 370 provided an inspector, and even then would likely not be customizable.</p>
 371
 372 <p>This problem can be generalized to apply to most debugging tools; it
 373 would be useful to write such tools portably because users of the
 374 <em>language</em> and not the <em>compiler</em> need to debug software. Sharing
 375 infrastructure would result in better tools (more developers), and
 376 save the man-years of wasted effort that comes with having to rewrite
 377 unportable tools from scratch multiple times.</p>
 378
 379
 380
 381 <h2><a name="sec12" id="sec12"></a>
 382 Metaobject Protocols</h2>
 383
 384 <h3><a name="sec13" id="sec13"></a>
 385 Limited/Generalized Internals of the Implementation</h3>
 386
 387 <p class="first">A Metaobject Protocol (MOP) is a generalized and limited subset of the
 388 underlying language implementation. It is limited to allow multiple
 389 implementation strategies; this, along with careful design, is
 390 essential because programming language research is ever advancing and
 391 new techniques for creating more reliable and faster implementations
 392 are still being discovered.</p>
 393
 394 <p>This subset of the implementation is exported as a set of methods on
 395 metaobjects. Thus the language is implemented in itself. The system
 396 can then be customized using the extension and overriding features of
 397 the language itself.</p>
 398
 399
 400 <h3><a name="sec14" id="sec14"></a>
 401 Classes of MOPs</h3>
 402
 403 <h4><a name="sec15" id="sec15"></a>
 404 Reflective</h4>
 405
 406 <p class="first">A reflective MOP provides an interface to information <em>about</em> the
 407 running system. It exposes class relationships, the methods attached
 408 to a generic, etc. A reflective MOP often provides some functionality
 409 for creating new classes at runtime. Smalltalk was one of the first
 410 languages to expose a reflective MOP.</p>
 411
 412 <h5>Example: Object Inspector</h5>
 413
 414 <pre class="src">
 415 (<span class="emacs-face-keyword">defgeneric</span> <span class="emacs-face-function-name">example-inspect</span> (instance)
 416   (<span class="emacs-face-builtin">:documentation</span> <span class="emacs-face-doc">"Simple object inspector using CLOS MOP"</span>))
 417
 418 (<span class="emacs-face-keyword">defmethod</span> <span class="emacs-face-function-name">example-inspect</span> ((instance t))
 419   (format t <span class="emacs-face-string">"Simple Object~% Value: ~S~%"</span> instance))
 420
 421 (<span class="emacs-face-keyword">defmethod</span> <span class="emacs-face-function-name">example-inspect</span> ((instance standard-object))
 422   (<span class="emacs-face-keyword">let</span> ((class (class-of instance)))
 423     (format t <span class="emacs-face-string">"Class: ~S, Superclasses: ~S~%"</span>
 424             (class-name class)
 425             (mapcar #'class-name
 426                     (class-precedence-list class)))
 427     (<span class="emacs-face-keyword">let</span> ((slot-names (mapcar #'slot-definition-name
 428                               (class-slots class))))
 429       (format t <span class="emacs-face-string">"Slots: ~%~{ ~S~%~}"</span> slot-names)
 430       (inspect-loop slot-names instance #'example-inspect))))
 431
 432 (<span class="emacs-face-keyword">defun</span> <span class="emacs-face-function-name">inspect-loop</span> (slots instance inspector)
 433   (format t <span class="emacs-face-string">"Enter slot to inspect or :pop to go up one level: "</span>)
 434   (finish-output)
 435   (<span class="emacs-face-keyword">let*</span> ((slot (read))
 436          (found-slot (member slot slots)))
 437     (<span class="emacs-face-keyword">cond</span> (found-slot
 438            (funcall inspector (slot-value instance slot))
 439            (funcall inspector instance))
 440           ((eq slot <span class="emacs-face-builtin">:pop</span>) t)
 441           (t
 442            (format t <span class="emacs-face-string">"~S is invalid. Valid slot names: ~S~%"</span>
 443                    slot
 444                    slots)
 445            (inspect-loop slots instance inspector)))))
 446 </pre>
 447
 448
 449 <h5>Example: Runtime Generated Classes and Methods</h5>
 450
 451
 452
 453 <h4><a name="sec16" id="sec16"></a>
 454 Intercessory</h4>
 455
 456 <p class="first">Intercessory MOPs allow the user to customize language behavior by
 457 implementing methods which override certain aspects of the language
 458 behavior. This class of MOPs are what make MOPs especially
 459 powerful. No longer must a problem be restructured to fit the
 460 implementation language; the underlying language can be reshaped to
 461 fit the task at hand, and obfuscation of the intended structure of the
 462 application can be avoided.</p>
 463
 464 <h5>Example: Lazily Allocated Slots</h5>
 465
 466
 467 <h5>Example: Observer Design Pattern</h5>
 468
 469 <p>A simple implementation of the observer pattern is under 100 lines,
 470 and the user level code requires only a single line of code to make
 471 any existing class observable.</p>
 472
 473 <p>In a language lacking a MOP, implementing the observer pattern
 474 requires modifying every accessor of a class to explicitly invoke any
 475 observers, and necessitates the addition of a mixin class to the class
 476 hierarchy. The fact that an object can be observed is a meta property
 477 of the class, and forcing it to be implemented at the application
 478 level dirties the inheritance hierarchy and adds unnecessary meta
 479 details to the program.</p>
 480
 481 <pre class="src">
 482 <span class="emacs-face-comment-delimiter">;;; </span><span class="emacs-face-comment">This metaclass adds a slot to instances which use it, and so the
 483 </span><span class="emacs-face-comment-delimiter">;;; </span><span class="emacs-face-comment">system is defined in its own package to avoid name conflicts
 484 </span>(<span class="emacs-face-keyword">defpackage</span> <span class="emacs-face-type">:observer</span>
 485   (<span class="emacs-face-builtin">:use</span> <span class="emacs-face-builtin">:cl</span> <span class="emacs-face-builtin">:c2mop</span>)
 486   (<span class="emacs-face-builtin">:export</span> observable register-observer unregister-observer))
 487
 488 (<span class="emacs-face-keyword">in-package</span> <span class="emacs-face-builtin">:observer</span>)
 489
 490 <span class="emacs-face-comment-delimiter">;;; </span><span class="emacs-face-comment">Metaclass
 491 </span>(<span class="emacs-face-keyword">defclass</span> <span class="emacs-face-type">observable</span> (standard-class)
 492   ()
 493   (<span class="emacs-face-builtin">:documentation</span> <span class="emacs-face-doc">"Metaclass for observable objects"</span>))
 494
 495 (<span class="emacs-face-keyword">defmethod</span> <span class="emacs-face-function-name">compute-slots</span> ((class observable))
 496   <span class="emacs-face-doc">"Add a slot for storing observers to observable instances"</span>
 497   (cons (make-instance 'standard-effective-slot-definition
 498                        <span class="emacs-face-builtin">:name</span> 'observers
 499                        <span class="emacs-face-builtin">:initform</span> '(make-hash-table)
 500                        <span class="emacs-face-builtin">:initfunction</span> #'(<span class="emacs-face-keyword">lambda</span> () (make-hash-table)))
 501         (call-next-method)))
 502
 503 (<span class="emacs-face-keyword">defmethod</span> <span class="emacs-face-function-name">validate-superclass</span> ((class observable)
 504                                 (super standard-class))
 505   t)
 506
 507 (<span class="emacs-face-keyword">defun</span> <span class="emacs-face-function-name">register-observer</span> (instance slot-name key closure)
 508   (register-observer-with-class (class-of instance)
 509                                 instance
 510                                 slot-name
 511                                 key
 512                                 closure))
 513
 514 (<span class="emacs-face-keyword">defun</span> <span class="emacs-face-function-name">unregister-observer</span> (instance slot-name key)
 515   (unregister-observer-with-class (class-of instance)
 516                                   instance
 517                                   slot-name
 518                                   key))
 519
 520 (<span class="emacs-face-keyword">defun</span> <span class="emacs-face-function-name">get-observers</span> (instance slot-name)
 521   (get-observers-with-class (class-of instance)
 522                             instance
 523                             slot-name))
 524
 525 (<span class="emacs-face-keyword">defun</span> <span class="emacs-face-function-name">add-observer-table</span> (instance slot-name)
 526   (setf (gethash slot-name (slot-value instance
 527                                        'observers))
 528         (make-hash-table)))
 529
 530 (<span class="emacs-face-keyword">defgeneric</span> <span class="emacs-face-function-name">register-observer-with-class</span> (class instance slot-name key closure))
 531 (<span class="emacs-face-keyword">defgeneric</span> <span class="emacs-face-function-name">unregister-observer-with-class</span> (class
 532                                             instance
 533                                             slot-name
 534                                             key))
 535
 536 (<span class="emacs-face-keyword">defmethod</span> <span class="emacs-face-function-name">register-observer-with-class</span> ((class observable)
 537                                          instance
 538                                          slot-name
 539                                          key
 540                                          closure)
 541   (setf (gethash key
 542                  (or (gethash slot-name
 543                               (slot-value instance 'observers))
 544                      <span class="emacs-face-comment-delimiter">;; </span><span class="emacs-face-comment">Lazily add observer hash tables
 545 </span>                     (add-observer-table instance slot-name)))
 546         closure))
 547
 548 (<span class="emacs-face-keyword">defmethod</span> <span class="emacs-face-function-name">unregister-observer-with-class</span> ((class observable)
 549                                            instance
 550                                            slot-name
 551                                            key)
 552   (remhash key (gethash slot-name
 553                         (slot-value instance 'observers))))
 554
 555 (<span class="emacs-face-keyword">defmethod</span> <span class="emacs-face-function-name">get-observers-with-class</span> ((class observable)
 556                                      instance
 557                                      slot-name)
 558   (gethash slot-name (slot-value instance 'observers)))
 559
 560 (<span class="emacs-face-keyword">defmethod</span> (<span class="emacs-face-function-name">setf slot-value-using-class</span>) <span class="emacs-face-builtin">:before</span> (new-value
 561                                                   (class observable)
 562                                                   instance
 563                                                   slot)
 564   (<span class="emacs-face-keyword">let</span> ((slot-name (slot-definition-name slot)))
 565     (<span class="emacs-face-keyword">if</span> (not (eq 'observers slot-name))
 566         (<span class="emacs-face-keyword">let</span> ((observers
 567                (get-observers instance (slot-definition-name slot))))
 568           (<span class="emacs-face-keyword">if</span> observers
 569               (maphash #'(<span class="emacs-face-keyword">lambda</span> (key observer)
 570                            (funcall observer
 571                                     (<span class="emacs-face-keyword">if</span> (slot-boundp instance slot-name)
 572                                         (slot-value instance slot-name)
 573                                       nil)
 574                                     new-value))
 575                        observers))))))
 576 </pre>
 577
 578
 579
 580
 581
 582 <h3><a name="sec17" id="sec17"></a>
 583 Violation of Encapsulation?</h3>
 584
 585 <p class="first">A MOP may seem like a violation of encapsulation by revealing some
 586 implementation details, but in reality a well designed protocol does
 587 not reveal anything which was not already exposed. Implementation
 588 decisions affect users, and some of these details do leak through to
 589 higher levels (e.g. the memory layout of slots). Implicit in the
 590 protocol specification are these implementation details, and the MOP
 591 merely makes this limited subset available for customization.</p>
 592
 593 <p>A MOP makes it possible to customize certain implementation decisions
 594 that do not <strong>radically</strong> alter the behavior of the base language. The
 595 conceptual vocabulary of the system retains its meaning, and so code
 596 written in one dialect can interact with code written in another
 597 without knowing that they speak different ones.</p>
 598
 599
 600
 601 <h2><a name="sec18" id="sec18"></a>
 602 MOP Design Principles</h2>
 603
 604 <h3><a name="sec19" id="sec19"></a>
 605 Layered Protocol</h3>
 606
 607 <p class="first">A layered protocol design is good for both meta and normal object
 608 protocols, and enables a combinatorial explosion of customizations to
 609 the protocol.</p>
 610
 611 <h4><a name="sec20" id="sec20"></a>
 612 Top Level <strong>Must</strong> Call Lower Level Methods</h4>
 613
 614 <p class="first">The top level methods of a layered protocol are required to call
 615 certain lower level methods to perform some tasks. This both makes it
 616 easier to customize the top level methods (which perform very broad
 617 tasks) by providing some pieces of implementation for the programmer,
 618 and enables more customization by opening up the replacement of lower
 619 level functions as a way to alter a small detail of the high level
 620 behavior.</p>
 621
 622
 623 <h4><a name="sec21" id="sec21"></a>
 624 Lower Level Methods are Easier to Customize</h4>
 625
 626 <p class="first">The lower level methods of a MOP are limited in scope and can be
 627 implemented easily. Often the desired changes to language behavior are
 628 minor, and having methods that perform simple tasks which are often
 629 customized reduces the effort required to extend the system.</p>
 630
 631
 632
 633 <h3><a name="sec22" id="sec22"></a>
 634 Functional Where Possible</h3>
 635
 636 <p class="first">Functional protocols are preferred for MOPs (and object protocols in
 637 general). Functional protocols open up several optimizations for the
 638 implementation without burdening the user of the protocol.</p>
 639
 640 <h4><a name="sec23" id="sec23"></a>
 641 Memoization</h4>
 642
 643 <p class="first">Memoization is the process of saving the results of a function call
 644 for future use. This avoids expensive recomputation of values which
 645 have not changed (recall that a true function will always return the
 646 same result when given the same arguments).</p>
 647
 648 <p>A functional MOP can be optimized easily by exploiting this property
 649 to memoize the return values of calls to expensive operations. A MOP
 650 must be be very fast to avoid making programs unusably slow, and
 651 memoization is able to give an appreciable speedup in many cases
 652 without a significant burden on memory usage.</p>
 653
 654
 655 <h4><a name="sec24" id="sec24"></a>
 656 Constant Shared Return Values</h4>
 657
 658 <p class="first">Disallowing modification of values returned by protocol methods allows
 659 the implementation to return large data structures by reference to
 660 avoid expensive copying without having to do expensive data integrity
 661 checks or copying.</p>
 662
 663
 664
 665 <h3><a name="sec25" id="sec25"></a>
 666 Procedural Only Where Necessary</h3>
 667
 668 <p class="first">Some operations like method invocation are inherently stateful and so
 669 must use a procedural protocol. There is no benefit to be gained from
 670 using a functional protocol, and indeed an attempt would result in
 671 obtuse code that severely restricted the implementation. Do note that
 672 only a very small part of method invocation is stateful (the actual
 673 call), and most of it can be implemented functionally (e.g. computing
 674 the discriminating function).</p>
 675
 676
 677 <h3><a name="sec26" id="sec26"></a>
 678 Real World</h3>
 679
 680 <h4><a name="sec27" id="sec27"></a>
 681 <a href="http://common-lisp.net/project/ucw/">UCW</a> and <a href="http://common-lisp.net/project/bese/arnesi.html">Arnesi</a></h4>
 682
 683 <p class="first">Arnesi uses the CLOS MOP to implement methods which are transparently
 684 rewritten into continuation passing style. This allows their execution
 685 to be suspended at certain points and resumed later. UCW builds on top
 686 of this to support a web framework where the statelessness of http is
 687 hidden from the user; displaying a page suspends the execution of the
 688 current continuation, and resumes it upon submission. The user level
 689 code is completely unaware of this.</p>
 690
 691
 692 <h4><a name="sec28" id="sec28"></a>
 693 <a href="http://clsql.b9.com">CLSQL</a></h4>
 694
 695 <p class="first">CLSQL uses the reflective part of the CLOS MOP to map Common Lisp data
 696 types into SQL types, and the intercessory protocol for slot
 697 allocation to map slots onto database columns or sql expressions (for
 698 implementing relational slots).</p>
 699
 700
 701 <h4><a name="sec29" id="sec29"></a>
 702 <a href="http://common-lisp.net/project/elephant/">Elephant</a></h4>
 703
 704 <p class="first">Elephant uses the CLOS MOP to transparently store any class to disk
 705 and handle paging between the disk store and memory efficiently
 706 without user intervention.</p>
 707
 708
 709
 710
 711 <h2><a name="sec30" id="sec30"></a>
 712 Sources and Further Reading</h2>
 713
 714 <h3><a name="sec31" id="sec31"></a>
 715 Sources</h3>
 716
 717 <h4><a name="sec32" id="sec32"></a>
 718 The Art of the Metaobject Protocol</h4>
 719
 720 <h5>Kiczales, Gregor et al. MIT Press 1991</h5>
 721
 722 <p>Highly recommended reading even if you plan to never implement a MOP
 723 or use the CLOS one. The design principles it recommends are quite
 724 useful.</p>
 725
 726
 727
 728 <h4><a name="sec33" id="sec33"></a>
 729 <a href="http://www.lisp.org/mop/contents.html">CLOS MOP Specification</a></h4>
 730
 731 <p class="first">Specification of the MOP for CLOS defined in <em>The Art of the Metaobject Protocol</em>.</p>
 732
 733
 734 <h4><a name="sec34" id="sec34"></a>
 735 <a href="http://citeseer.ist.psu.edu/399658.html">Metaobject Protocols: Why We Want Them and What Else They Can Do</a></h4>
 736
 737 <p class="first">A short overview of MOP design principles followed by three example
 738 metaobject protocols for Scheme.</p>
 739
 740
 741 <h4><a name="sec35" id="sec35"></a>
 742 <a href="http://www2.parc.com/csl/groups/sda/projects/oi/towards-talk/transcript.html">Why Are Black Boxes so Hard to Reuse?</a></h4>
 743
 744 <p class="first">Transcription of a talk on the benefits of open implementations of
 745 software. It first discusses several problems that black box software
 746 implementations pose, and then presents existing solutions. It shows
 747 how the existing solutions are insufficient, and then provides
 748 metaobject protocols as a solution to most of the problems.</p>
 749
 750
 751
 752 <h3><a name="sec36" id="sec36"></a>
 753 Further Reading</h3>
 754
 755 <h4><a name="sec37" id="sec37"></a>
 756 <a href="http://citeseer.ist.psu.edu/chiba95metaobject.html">A Metaobject Protocol for C++</a></h4>
 757
 758 <p class="first">Example of a purely compile time MOP. It implements the functionality
 759 of a code walker and something similar to the Lisp macro system.</p>
 760
 761
 762 <h4><a name="sec38" id="sec38"></a>
 763 <a href="http://www.parc.com/csl/groups/sda/publications/papers/Kiczales-TUT95/for-web.pdf">Open Implementations and Metaobject Protocols</a></h4>
 764
 765 <p class="first">It is a bit long, but it seems to follow a similar structure to AMOP
 766 in introducing MOPs and their usefulness. The pages are slides with
 767 notes, and so the 331 pages might not actually take that long to read.</p>
 768
 769
 770
 771 <h3><a name="sec39" id="sec39"></a>
 772 Software</h3>
 773
 774 <h4><a name="sec40" id="sec40"></a>
 775 <a href="http://common-lisp.net/project/closer/closer-mop.html">Closer to MOP</a></h4>
 776
 777 <p class="first">Compatibility layer that attempts to present the <em>Art of the Metaobject
 778 Protocol</em> MOP specification properly in as many Common Lisp
 779 implementation as possible.</p>
 780
 781
 782
 783
 784   <!-- Page published by Emacs Muse ends here -->
 785
 786   <p class="cke-buttons">
 787     <!-- validating badges, any browser, etc -->
 788     <a href="https://validator.w3.org/check/referer"><img
 789         src="https://www.w3.org/Icons/valid-xhtml10"
 790         alt="Valid XHTML 1.0!" /></a>
 791
 792     <a href="https://www.anybrowser.org/campaign/"><img
 793         src="img/buttons/w3c_ab.png" alt="[ Viewable With Any Browser
 794         ]" /></a>
 795
 796     <a href="https://www.debian.org/"><img
 797         src="img/buttons/debian.png" alt="[ Powered by Debian ]" /></a>
 798
 799     <a href="https://hcoop.net/">
 800       <img src="img/buttons/hcoop.png"
 801         alt="[ Hosted by HCoop]" />
 802     </a>
 803
 804     <a href="https://www.fsf.org/register_form?referrer=114">
 805       <img src="img/buttons/fsf_member.png"
 806         alt="[ FSF Associate Member ]" />
 807     </a>
 808   </p>
 809
 810 <p class="cke-footer">&lt;ascii_phil&gt; There once was a man named Bertold
 811 &lt;ascii_phil&gt; Who drank beer when the weather grew cold
 812 &lt;ascii_phil&gt; As he reached for his cup...
 813 &lt;ascii_phil&gt; "NEEEEVER GONNA GIVE YOU UP!!!"
 814 &lt;ascii_phil&gt; Oh, snap! You just got limerickrolled!
 815 </p>
 816 <p class="cke-timestamp">Last Modified:
 817     January 21, 2013</p>
 818   </body>
 819 </html>